1. Prior Art
In classic telephony (STN or switched telephony network), telephony operators set up bilateral agreements to extend the overall coverage of the telephone service. The level of coverage attained essentially depends on the number of agreements made. Very roughly, we may assume that there are two categories of telecommunications operators: local operators and/or national operators and worldwide operators. The major worldwide operators set up a large number of agreements and can thus link up with most existing destinations. Local operators set up only a limited number of agreements and for example only one or two agreements with the major operators. Thus a historic national operator in a developing country will make agreements with other national operators and one or two agreements with worldwide operators to send communications to the rest of the world.
At present, most operators migrate or are thinking of making their STN networks migrate towards solutions and infrastructures based on the IP network. To work along with the deployment of VoIP services, the IETF (Internet engineering task force) has launched many standardization tasks. Several protocols have thus been specified, among them:                SIP (Session Initiation Protocol)        SDP (Session Description Protocol)        RTP (Real-time Transfer Protocol)        RTCP (Real-time Transfer Control Protocol)        MGCP (Multimedia Gateway Control Protocol)        SAP (Session Announcement Protocol) and        TRIP (Telephony Routing Over IP, [RFC3219])        
These protocols meet different needs and especially incorporate the signaling and control of calls, the exchange of media streams and their control and the exchange of information for the routing of the calls.
For further information on the TRIP protocol, reference may be made to the standardization document RFC3219. The present disclosure can be implemented especially but not exclusively in the context of this RFC3219 specification.
The TRIP protocol enables interconnected ITADs to exchange all the destinations that they can link up to and facilitates especially the selection of the gateway (motorway or backbone) most appropriate to sending IP telephony traffic to the STN network. The TRIP protocol is implemented by the LS (location servers) which propagate TRIP routes containing attributes used to define the routes in question. The use of this special protocol is independent of the type of signaling protocol deployed for the effective establishment of the calls. The TRIP protocol can be used jointly with the SIP, H.323 or any other signaling protocol.
Each LS maintains a local routing database called TRIB (telephony routing information database). This routing database is fed with announcements received from neighboring LS (from another telephony domain for example). The working of the TRIP protocol is similar to that of the BGP (border gateway protocol). The announcements between LS neighbors are made in the form of route updating messages called UPDATE messages. These messages are defined by the TRIP protocol and are exchanged between the LSs to inform an LS of the same domain or of the neighboring domain about the routes available.
Referring now to FIG. 9, a description is provided of the activation of the TRIP protocol between different ITADs (here below, we shall also use the term “telephony domain” or simply domain to designate an ITAD), each ITAD being administered by a single telephony operator. These operators each have one or more LSs and one or more proxy servers (or PS). Each LS maintains a routing base which he feeds with announcements received from his neighbours (situated in another domain) and LSs of his own domain. These announcements are updated and distributed to other neighbors if the agreements permit it. Each PS is responsible for setting up calls and processing signaling information received from clients or other PSs.
In FIG. 9, only the LSs are shown. Thus, ITAD4 84 for example updates the announcements received from the ITAD5 85 and re-propagates them to ITAD3 83. It must be noted that when an ITAD is not necessarily deployed on a single IP transfer domain also called an AS.
From a routing viewpoint, an LS may process three types of routes:                external routes provided by the LSs situated in the neighboring ITADs;        internal routes provided by the LSs situated in the same ITAD;        local routes configured locally in each LS to be injected into the TRIP process. This operation is performed either by static configuration or by redistribution of information coming from other routing protocols.        
Thus, four types of TRIB are generated by an LS as illustrated in FIG. 10. These tables exist for a same LS. The relationships between these tables are illustrated with reference to FIG. 10. These tables comprise:                Adj-TRIBs-In 92 (Adjacent TRIB in): this table stores the routing information conveyed by update messages. These pieces of routing information, also called routes, are the inputs of a route selection process 91 (decision process). A given LS keeps an Adj-TRIB-In 92 (adjacent TRIB-in which stores all the route announcements received from an adjacent LS) per neighboring LS;        Ext-TRIB 94 (External TRIB): this table contains the result of a route selection process applied to the external routes 95 (Adj-TRIBs-IN) and local routes 96 (local routes). Only one Ext-TRIB table (external TRIB table) is kept per LS. The prior-art techniques make it possible to choose only one route per destination;        Loc-TRIB 90 (Local TRIB): this table contains the local routes resulting from the application of the local routing policies to each LS;        Adj-TRIBs-Out 93 (Adjacent TRIB out): this table contains the routes that the local LS will announce to its peers.        
The TRIP protocol is used to store one and only one route per destination in the local TRIB. This route is the one announced to the peers of a given LS, i.e. to the neighboring LSs (which may be in the same ITAD or in a different ITAD) when there is an agreement between then. To this end, TRIP implements a route selection process to determine the best route to be stored in its local TRIB. If a route to this destination already exists, then the selection process is invoked. If this new route is chosen by the process, it replaces the former one in the local TRIB.
2. Drawbacks of the Prior Art
One drawback of this prior-art technique is that it cannot be used to take account of and manage blockages or congestion phenomena in a domain or congestion in the external links of this domain with other neighboring domains. These phenomena may for example be due to overloading (in terms of the numbers of communication links to be processed simultaneously or malfunctions for example). In other words, the current technique does not propose means to manage the resilience of the routes announced by the TRIP protocol and especially to cope with the phenomena of congestion of telephony routes between the ITADs.
A congestion phenomenon may correspond especially (and not only) to:                an incapacity of an ITAD to process calls following an insufficiency or unavailability of resources for routing calls;        an impossibility for a given ITAD to take account of calls formulated by subscribers of the domain; and/or        an impossibility of routing calls to a given destination, such as another ITAD, or again a difficulty for transmitting calls to the subscribers of the ITAD.        
This may be due for example to the use of the bandwidth (BW) reserved for the telephony streams (the available bandwidth is close to zero), rate of active sessions close to the threshold borne by a telephony apparatus, an unavailable IP link, an unavailable link between two ITADs or an available bandwidth value close to zero.
Such phenomena may occur especially within interconnection gateways of the telephony domains (ITAD). Indeed, according to current techniques, one and only one route is announced if it exists for a given destination. Now, in the context of VoIP/ToIP, congestion phenomena may arise between the telephony domains. To date, there is no mechanism enabling the operator managing this domain to inform the operators of neighboring domains about the existence of this congestion phenomenon. The distant domains that do not possess mechanisms to inform them on the state of a route (whether congested or not) continue to select this route. The communications therefore cannot reach their destination.
An illustrative embodiment of the present invention makes it possible to find a solution to this technical problem.